经典的瀑布开发模型包含以下阶段:
每个阶段都有明确的产出物:
| 阶段 | 产出物 | 目的 |
|---|---|---|
| 需求分析 | 需求规格说明书 | 明确做什么 |
| 系统设计 | 架构设计文档 | 确定怎么做 |
| 详细设计 | 接口设计文档 | 细化实现方案 |
| 编码实现 | 源代码 | 实现功能 |
| 测试阶段 | 测试报告 | 验证质量 |
传统流程虽然严谨,但各阶段割裂明显,文档与代码易脱节,且需要大量人工协调。 针对文档与代码脱节的问题,目前有两种主流的 AI 工作流方案:
GitHub Spec Kit — 规格驱动开发(Spec-Driven)
GitHub 官方推出的 Spec Kit 把规格文档变成可执行的制品,让 AI 直接从规格生成计划和代码。流程分 6 步:constitution→specify→clarify→plan→tasks→implement。核心思路是「自顶向下」——先写完整规格,再逐步细化到代码。适合从零开始的新项目,或需要跨团队对齐需求的场景。
Superpowers — 技能驱动开发(Skill-Driven)
社区项目 Superpowers 走的是「渐进式」路线——不要求预先写完整规格,而是通过 brainstorming 在对话中逐步收敛需求,技能会主动读项目代码,基于已有实现提出针对性问题。流程分 4 步:brainstorming→writing-plans→executing-plans→debugging。适合在已有项目上做功能迭代。
两者本质上解决的是同一个问题:把传统软件工程的文档流程融入 AI 编程过程。区别在于,Spec Kit 要求先把规格文档写好落盘,再交给 AI 执行;而 Superpowers 的文档不需要落盘,而是在对话中实时生成、实时交给 AI 理解——因为编码工作本身就是由 AI 完成的,文档的消费者就是 AI,没必要走传统的文档归档流程。
我们推荐使用 Superpowers 这类技能驱动的方案。原因很简单:在 AI 编程场景下,文档的目的不再是给人看,而是给 AI 提供上下文。brainstorming 产出的设计文档直接作为 writing-plans 的输入,plans 产出的任务列表直接作为 executing-plans 的输入,整个链路在对话中闭环,不存在文档与代码脱节的问题。本文以 Superpowers 为例展开。
AI 编程助手(包括 Claude Code)在没有约束的情况下,容易出现以下问题:
模糊需求,跳过规划,直接写代码
缺少分解,一次性实现
Superpowers 将瀑布模型的每个阶段映射为 AI 可执行的技能,用强制性工作流替代人工协调:
| 维度 | 传统瀑布流程 | Superpowers 工作流 |
|---|---|---|
| 阶段划分 | 需求→设计→编码→测试 | brainstorming→plans→executing→debugging |
| 产出物 | 文档和代码分离 | 文档驱动代码生成 |
| 验证时机 | 测试阶段集中验证 | 每个任务完成后立即验证 |
| 可追溯性 | 依赖文档维护 | 对话历史自动记录 |
| 灵活性 | 阶段间难以回退 | 任何阶段都可回退重来 |
实线表示正常流程,虚线表示遇到问题时的分支。每个阶段都有明确的产出物,作为下一阶段的输入,确保开发过程可追溯、可回滚。
安装后技能会自动生效,Claude Code 会在合适的时机自动调用对应技能,无需手动指定。
| 技能 | 触发时机 | 产出物 | 对应传统阶段 |
|---|---|---|---|
| brainstorming | 开始任何新功能前 | 设计文档 | 需求分析 + 系统设计 |
| writing-plans | 有设计或需求后 | 实现计划 | 详细设计 |
| executing-plans | 有计划后 | 代码实现 | 编码 + 单元测试 |
| debugging | 遇到 bug 或异常时 | 根因分析与修复 | 问题排查 |
| 阶段 | 输入 | 输出 | 验证标准 |
|---|---|---|---|
| brainstorming | 模糊需求 | 设计文档 | 需求明确、无歧义 |
| writing-plans | 设计文档 | 任务计划 | 任务粒度适中、依赖清晰 |
| executing-plans | 任务计划 | 代码实现 | 编译通过、符合设计 |
| debugging | 错误现象 | 根因修复 | 问题不再复现 |
以 PIGX 项目的 OA 模块为例,演示从模糊需求到清晰设计的完整流程。
项目中请假模块已有完整审批流程,但报销模块只有基础 CRUD,缺少审批——这是实际存在的功能缺口。选择这个场景有三个原因:
用户输入模糊需求后,brainstorming 技能自动介入,通过一系列问题把需求变成清晰设计。
触发示例:
这句话故意模糊——「参考请假模块」到底参考到什么程度?报销有哪些特殊性?这些都没说清楚。
问答过程:
Claude 会逐个提问,每次只问一个问题。brainstorming 会先读现有代码,发现 LeaveStatusEnum、BmpOaLeaveAudit、RabbitMQ 配置等,基于项目实际情况提问:
brainstorming 技能每次只问一个问题,避免信息过载。通过多轮对话逐步明确需求细节,确保设计文档完整准确。
产出文档示例:
设计文档确认后,用户表示"准备开始实现",Claude 调用 writing-plans 技能,将设计拆分为可执行的任务列表。
任务列表示例:
依赖关系:
每个任务粒度适中,可独立验证。用户可以在此阶段调整任务顺序或增删任务。
计划确认后,Claude 调用 executing-plans 技能,按批次推进任务。
批次执行机制:
不是一次性执行所有任务,而是分批进行。每批完成后暂停,等待用户确认后继续。
执行过程示例:
验证机制:
每个任务完成后自动检查:
如果中途退出 Claude Code,重新进入后可以继续执行未完成的计划,进度不会丢失。
执行过程中遇到错误时,debugging 技能介入进行系统化排查。
场景示例:
报销提交审批后,金额 > 1000 的单据没有流转到总监,直接变成了「已通过」。
排查流程:
debugging 技能强调先验证假设再修复,避免盲目修改代码引入新问题。系统化的排查流程确保问题得到彻底解决。